home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SPACE 1
/
SPACE - Library 1 - Volume 1.iso
/
program
/
113
/
gfatip07
/
gfatip07.doc
< prev
Wrap
Text File
|
1987-09-25
|
18KB
|
355 lines
August 15, 1987
GFATIP07.DOC
by John B. Holder
Senior Software Engineer
Marathon Computer Press
Asst. Sysop on GEnie's MichTron Roundtable
This is the 7th in a planned series of GFA Tip files. The
topic of this issue is source code control and .LST file linking.
Before we get into the nitty gritty of the subject, a bit of
background is necessary first.
In most of the heavy duty languages such as C, Modula 2,
Pascal, and Assembler there is usually a utility that will either
help you to track a project's progress as you develop it and
thereby allowing total control over a modular development project.
In the UNIX(tm) world there are many utilities to aid you in this
pursuit. They are TOUCH, MAKE, and DIFF to name just a few.
Since Marathon Computer Press is always working on a multitude of
projects at any time, it is easy for one of our staff programmers
to be involved in more than one project at a time. Speaking for
myself, I am sometimes working on 3-4 at a time, so source code
control becomes a paramount concern. How many times have you been
working on a programming project, and have to set it aside for a
week or two, then when returning you don't remember where you were
at or file names appear different? If you've been programming for
more than just a short time, this will occur rather frequently
unless you are much more organized than the bulk of us.
How does this pertain to this GFA Tip file? Well, I
personally found a need for some sort of scheme to store my
various GFA Basic source code files when they began to approach 3
Megabytes, so I decided to devise a storage & linkage scheme.
Since my GFA Environment is on an ATARI SH204(tm) hard disk, I
chose not to use ARC.TTP to archive my files since room was not
really a concern. The main concern for me was keeping track of
the massive amounts of files, and then how to bring them all
together in a programming project without having to use the GFA
Basic editor to first Save a .LST file then load a .BAS file and
merge the two and save the new .BAS file composed of the two
parts. Sound pretty complicated.... Well it's not really, but
then again anything that will save time is very important to me.
Being in the computer software business I have learned to
associate time with money. I would like to offer a few
suggestions to you and make a few points concerning source code
control before going into the mechanics of GFALINK.TTP.
Suggested DO's
1. Always set the current Date & Time on your system before
starting a programming session.
2. Set up separate directories for your .LST, .BAS, and .PRG
files. ( And use them religiously! )
3. Keep good control over .BAK files and delete them when they
are no longer necessary.
4. Move files that you no longer really use to a backup storage
floppy diskette. ( Makes more room to work with on your primary
working drive )
By following the above suggestions, you will have about 60%
of the battle licked, but there is more...
With the introduction of PASCAL in the early 70's, C in the
mid 70's and Modula in 1976 people were introduced to structured
programming. Some of the concepts presented by Prof. Niklaus
Wirth of Swiss Federal Institute of Technology, (ETH,
Eidgenossische Technische Hochschule) have established him as the
father of the Structured Languages. His most notable
accomplishments include PASCAL and his latest successor to that
language, MODULA 2. These languages set themselves apart
from the earlier languages such as FORTRAN (1956), and BASIC
(Circa 1962), by differing radically from these venerable old
beasts in a multitude of ways.
In the earlier languages the primary Control Structure was
the GOTO command. The use of these structures caused the execution
of the programs to jump back and forth within code at any whim of
the programmer, thereby making it extremely difficult both to
trace the code and to identify errors. Hence, the word Structured
Programming came from the Strongly Type Checked languages of Pascal
and Modula 2. The use of procedures within a program allowed a
logical flow of control within a program and was the tool whereby
code was made infinitely more readable and maintainable. This
art has improved over the years, and now Prof. Wirth's latest
endeavor lends itself totally to the modular programming concept,
alas the name of Modula 2. With Modula 2 everything is a Module,
and procedures are the main structures within the module.
You may ask, how does this pertain to GFA Basic? Well, the
systems programmers at GFA Systemtechnik set out to develop a new
Basic that would retain the better parts of the original forms of
Basic, yet incorporate the better parts of the Structured
languages such as Pascal or Modula 2. However, they did not
provide any source code control utilities other than the GFA Basic
Interpreter's own inherent editor. They left the control of code
up to you. That's where the Linker comes in...
GFALINK.TTP Instructions and usage
I found it infinitely more manageable to use GFA Basic's
structure to help me build libraries for use with my projects. By
this I mean that I set up my environment by building little
software chips in the form of procedures and put them on the shelf
so to speak, ready to be pulled off the shelf and used in any
project I chose. How do you accomplish this task? It's so
simple, you'll be doing it in no time at all. Just develop a
procedure to accomplish a specific task, such as a time changing
routine, a drive map routine, or whatever. Next, snip out the
procedure using the Mark Block and Write Block routines within the
GFA Basic Editor. Save the procedure as a .LST file in your .LST
folder, (previously established). By doing this you have created
a procedure for your current project, but you have also set aside
that tiny little software chip to use on another day with another
project. This saves you a ton of time in either trying to
reinvent the wheel in a new project or searching through reams of
code you created earlier trying to find the elusive routine that
you need now. This practice of building library functions or
procedures to be used at a later date is a corner stone of Modula
and the newest of the structured programming languages, ADA. If
you want to create your own libraries from programs you have
created and are currently in .BAS file format, then use the editor
to snip out and save those procedures in .LST file format, ready
to be merged in a future endeavor.
A word of caution is in store here. You should identify all
of your variables and strings within the procedure at the top
either in REM statements or a series of Equates. Example:
Procedure Do_this_thing
Rem Created 8/15/87
A_number=100
A_string="This is the Do_this_thing Procedure"
.
.
. Body of the procedure
Return ! Do_this_thing Procedure
By doing this you will have to take a bit more time, but it
will save you many headaches by not having to try to find out why
a variable keeps getting changed, (If it's used in another
procedure). Keep track of your LOCAL variables also, because you
are sure to crash your system if you call or try to use a LOCAL
variable outside of the Parent Procedure.
Now you might say "Gee .. Thanks for the advice, but I still
don't understand what GFALINK.TTP will do for me!". For those
people here is the answer:
Place a copy of your GFALINK.TTP program in your .LST folder
along with all of the modules that you have created, (by storing
procedures in .LST file format with the GFA Basic editor). Any
time in the future, if you need to use say 4 or 5 of your software
chips, it's as simple as double clicking on GFALINK.TTP and
entering the following on the command line:
file1.lst file2.lst file3.lst newfile.lst
Next click on OK and your files will be joined effortlessly
for you into the file you name as "newfile.lst", or whatever you
want your output file to be named. In essence it has performed a
multi-file merge without using the GFA Basic Editor and having to
step through the Merge+File select box+OK for each of the files
you choose to "link together".
Warnings:
1. Be sure to give the last file in the command line a unique
name, (One different from all other .LST files within the
directory), or you'll erase the old file. Also don't forget to
give the "newfile.Lst" name or the last file in the link will be
replaced by the newly created LINK'ed file.
2. The GFALINK.TTP file must reside in the same directory as all
files to be included in the link, or the link will fail.
Suggestions:
For the most successful use of GFALINK.TTP, I would suggest
that you get a good CLI (command line interpreter), such as
MichTron's DOS Shell by Timothy Purves. Since the command line
that appears from the desk top is limited, you can only merge a
few files at a time in this manner. However, with DOS Shell, (or
a CLI) you can enter many many more files into the link at a
single time. It will all depend on the CLI and how many
characters can be on a single command line. Dos Shell can allow
up to 128 characters on a command line. Or you may choose to
automate a GFALINK sequence with a .BAT file. A Bat file allows
you to enter a number of commands in a file to be sequentially
executed by the CLI when called on.
For those that dabble with C, this procedure gives a GFA
Basic programmer the ability to create his own form of UNIX's(tm)
Make Utility. You could create a Makefile.Bat to be executed by a
CLI. In this makefile you would call on GFALINK.TTP to link
several modules for you and then chain to either the compiler or
interpreter. You will have to refer to the instructions that come
with your CLI to see how to set up .BAT files and execute GEM
programs. For example DOS Shell uses the command RUN to execute a
GEM(tm) program such as the GFA Basic Compiler or Interpreter.
Technical Aspects of GFALINK.TTP
Since this program is not GEM(tm) based it can be run from
most CLI's without having to rename it with a .PRG suffix, and
will normally not require any special pre-command to execute. The
Linker itself was created with the Lattice C vers. 3.03.04
compiler. C was chosen to enable the reading of commands (file
names) passed to the program from a shell (CLI).
The linker will accept up to 26 files in the link, but this
may be limited by the length of the file names and the command
line buffer. I would suggest that you only attempt to link 10-15
files at the maximum in a single step. If you have more you can
do a series of linking actions. Just use the subsequent
"newfile.lst" as the first file in the second step linking
command. Just be sure to name the next output file as something
different that the first such as "newfile2.lst" instead of
"newfile.lst" to prevent spooling on top of the first file in the
successive link.
The linker is very fast, but is I/O intensive. No buffers
have been established so there is not a burden on memory in most
cases. Very Large Files will take a long time in the link so be
patient. It should still save you time compared with the GFA
Basic Merge process even if you have exceptionally large .LST
files in your link. It was designed to link files in the 1K to
25K size range, but will work with any size file. You will find
that GFALINK.TTP will link together any data files or ASCII files
you might desire to join, so you may use this utility elsewhere.
It will not successfully merge GFA Basic .BAS file format files,
so don't try. It'll join them for you, but the editor will not
recognize any files beyond the first.
Disclaimer:
As with any program that writes data to your disk, you should
read the operation instructions presented above thoroughly before
trying to use GFALINK.TTP. It will do what you tell it to, so be
sure all of the filenames are unique on output, or it'll write
over an existing file.
This program has been placed in the public domain as a Free
of Charge utility. You accept full response for the use of the
program and it's your responsibility to decide it's applicability
for fitness for a particular purpose. Neither myself, nor MCP
will be responsible for any damages to your equipment, files, or
computer resulting from the use of this Public Domain Utility
Program.
(c) Copyright Notification
This utility is a copyrighted utility program by the name of
GFALINK.TTP. (c)1987 Marathon Computer Press, All rights are
reserved. It has been placed in the public domain for the
exclusive use of Legal owners of GFA Basic, and the GFA Basic
Compiler only. It may not be distributed in any Public Domain
program package that any fee at all is assessed. You may post it
on any BBS that you choose, however if you want to sell it as a
part of any package you must contact:
Marathon Computer Press
P.O. Box 68503
Virginia Beach, Virginia 23455
If you liked this program, drop us a letter at the above
address. We'd like to hear from you.
Or drop us an EMAIL letter on :
Genie = GRIFJOHN
CIS = 75766,505
I hope that at least some of the concepts presented in this
GFATIP file will help you to be a more productive programmer, and
if the GFALINK.TTP program will help you then all the much better.
I've included the Press Release for The GFA Basic Companion(tm) at
the bottom of this Doc file because the concept is graphically
carried out by the Source Code Generator within the Companion.
It's truly destined to make you change the way you think about
programming in GFA Basic. Besides I thought I'd try to get a
commercial in since I had your attention. Have fun!
John B. Holder
Press Release
*****************************************************************
For further information contact:
Gordon Monnier
President, MichTron
For Immediate Release:
MichTron announces the release of The GFA BASIC
Companion, a dedicated RCS package designed to create dialog
boxes and more for GFA BASIC programs.
GFA BASIC owners now have a new, incredibly useful tool
available that will cut the time and annoyance often (if not
always) associated with programming in GEM with BASIC.
Already the possessors of the best BASIC available for any
computer, GFA users can now build Radio Button Boxes, Dialog
Boxes, Help Text Boxes, Sliders, Error Boxes, and more with
The GFA BASIC Companion. They can even design their own
custom boxes with the companion's amazing dialog box source
code generator.
Best of all, these objects, once created, are stored in
GFA BASIC's ASCII.LST file format so they can be studied,
modified, or merged into a GFA BASIC program.
The GFA BASIC Companion Dialog box source code
generator produces quick Dialog Boxes easily so even the
newest programmers can give their programs an elegant,
professional look, but the Custom Design Option gives the
total control and creativity necessary to satisfy the
hungriest of "power users".
The GFA BASIC Companion will change the way you think
about programming in GFA BASIC on the ST. You'll find that
by using several of the GFA BASIC resident commands you can
create a versatile user interface that will mimic routines
available in the GEM AES, but in an adaptive format that is
easier to learn and change. Altering one of these routines
is simply a matter of loading the BAS. or LST. file into the
GFA BASIC Editor and changing the desired portions in a real
time mode that allows immediate testing of all your changes.
This isn't possible in a standard RCS, such as the one
included in the ATARI ST developers kit. Consider the time
that will be saved and the headaches that will be cured by
such an interface.
Other attractions of The GFA BASIC Companion include an
extensive online Tutorial that may be viewed from a window,
or printed out for further study.
A demonstration of this amazing product can be
Downloaded from the CompuServe ATARI 16 libraries or from
GEnie's Michtron Roundtable. If you would like
to take a look at the capabilities of The GFA
BASIC Companion, you may send for a Demo Disk. Specify
color or monochrome and send five dollars ($5) to :
MichTron,Inc.
576 South Telegraph
Pontiac, Michigan 48053
(313) 334-5700
The GFA BASIC Companion is an exciting addition to your
library of GFA BASIC products and is available from MichTron
for $49.95.
-END-